Default data session for a wireless communication network

ABSTRACT

Aspects of the present disclosure are directed to communication between a policy engine and a charging engine of a wireless communication network. In one example, the charging engine maintains a data store that includes counters and corresponding service identifiers of one or more subscribers of the wireless communication network. In operation, the charging engine receives a status request message from the policy engine, where the status request message is a request for information on a counter associated with a service identifier. The charging engine may determine that the service identifier is not included in the data store and in response thereto generate a default response message that includes nominal data. The charging engine then sends the default response message to the policy engine to enable the policy engine to implement a default policy for allowing a data session between a user device and the wireless communication network.

BACKGROUND

Wireless communication devices are integral to the daily lives of mostusers. Wireless communication devices are used to make voice calls,check email and text messages, update social media pages, stream media,browse websites, and so forth. These wireless communication devices mayperform such communication by establishing a data session with awireless communication network operated by a mobile network operator(MNO).

For example, LTE Long-Term Evolution (LTE) is a standard for wirelesscommunication of high-speed data for wireless communication devices. Insome aspects, an MNO may provide a wireless communication network thatallows for Voice over LTE (VoLTE), in which two-way voice communicationis delivered via a data session that is established between a wirelesscommunication device and the wireless communication network.

As the usage of wireless communication networks become more prevalent,the users of wireless communication devices expect telecommunicationcarriers to provide constant and reliable telecommunication and datacommunication services.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanyingfigures, in which the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Theuse of the same reference numbers in different figures indicates similaror identical items.

FIG. 1 illustrates an example architecture of a core network in awireless communication network that implements the establishment of adefault data session between a user device and the wirelesscommunication network.

FIG. 2 is a block diagram showing various components of one or morecomputing devices that support the establishment of a default datasession in a wireless communication network.

FIG. 3 is a flow diagram of an example process for establishing adefault data session in a wireless communication network.

FIG. 4 is a flow diagram of an example process for switching from adefault data session to an updated data session for a user device andwireless communication network.

FIG. 5 is a diagram of an example response message generated by acharging engine of a wireless communication network.

FIG. 6 is a block diagram showing an example call flow for establishinga default data session and for switching between the default datasession and an updated data session for communications between a userdevice and a wireless communication network.

DETAILED DESCRIPTION

In some aspects, a wireless communication network may include a corenetwork that provides telecommunication and data communication servicesto multiple user devices. For example, the core network may connect theuser devices to other telecommunication and data communication networks,such as the Internet and a public switched telephone network (PSTN). Thecore network may include several components that support a variety ofservices provided to subscribers of the wireless communication network.For example, the core network may include a policy engine and a chargingengine.

In general, the charging engine is a system that allows a mobile networkoperator (MNO) to charge their customers (i.e., subscribers), in realtime, based on service usage. The charging engine may maintain severalcounters to monitor the various services offered. The policy engine is asystem that aggregates information to and from the network, operationalsupport systems, and other sources (such as portals) in real time. Thepolicy engine also supporting the creation of rules and automaticallymakes policy decisions for subscribers active on the network. Inoperation, the policy engine communicates with the charging engine toobtain current usage metrics for a subscriber and then implements one ormore policies by communicating with a gateway of the core network.

Upon the initiation of a data session by a user device (e.g., uponpowering up the user device), both the policy engine and the chargingengine are provisioned with subscriber information (e.g., serviceidentifiers, plan subscriptions, etc.). When the policy engine isprovisioned, it initially communicates with the charging engine toobtain session information (e.g., counter status). However, often thepolicy engine and charging engine are implemented as autonomous systems.That is, the provisioning of the policy engine and the charging enginemay be asynchronous. Thus, in some scenarios the charging engine may notbe provisioned yet when the policy engine initially communicates withthe charging engine to obtain the current session information. Inresponse, the charging engine may generate an error message which mayprevent the establishment of a data session between the user device andthe wireless communication network.

Accordingly, aspects of the present disclosure are directed tocommunication between the policy engine and the charging engine of acore network to enable the establishment of a default data session. Inparticular, aspects of the present disclosure include modifying thecharging engine's response to the initiation of a data session when thecharging engine is not yet provisioned with the current subscriberinformation. For example, the charging engine may be modified togenerate a default response message that includes nominal data thatidentifies a session as a default data session rather than generating anerror message.

In response to receiving the default response message, the policy enginemay implement default policies by communicating one or more rules to thegateway of the core network to enable the default data session.Furthermore, in some aspects, once the charging engine is eventuallyprovisioned with the current subscriber information, the charging enginemay subsequently notify the policy engine with an updated responsemessage so that the policy engine may implement the appropriate policiesbased on the correct counter status for that specific subscriber.

Accordingly, the techniques described herein may prevent the failedestablishment of a data session between a user device and the wirelesscommunication network, and instead may allow for the creation of adefault data session. As discussed above, such a failure may occur inconventional systems due to the asynchronous nature of one or more ofthe components of the core network. The failure of the establishment ofa data session has the potential to detrimentally affect the ability ofsubscribers to access the data services provided by the wirelesscommunication network. The techniques described herein may beimplemented in a number of ways. Example implementations are providedbelow with reference to the following figures.

Example Architecture

FIG. 1 illustrates an example architecture 100 of a core network 108 ina wireless communication network 102 that implements the establishmentof a default data session 134 between a user device 104 and the wirelesscommunication network 102. The architecture 100 may include the wirelesscommunication network 102 that serves multiple user devices, such as theuser device 104. The user device 104 may be a feature phone, asmartphone, a smart watch, a tablet computer, a phablet, an embeddedcomputer system, or any other device that is capable of using thewireless communication services that are provided by the wirelesscommunication network 102.

The wireless communication network 102 may include multiple basestations, such as the base station 106, as well as a core network 108.The wireless communication network 102 may provide telecommunication anddata communication in accordance with one or more technical standards,such as Enhanced Data Rates for GSM Evolution (EDGE), Wideband CodeDivision Multiple Access (W-CDMA), High Speed Packed Access (HSPA), LongTerm Evolution (LTE), CDMA-2000 (Code Division Multiple Access 2000),and/or so forth. The base stations are responsible handling voice anddata traffic between user devices and the core network 108. In someexamples, the base stations may be in the form of eNodeB nodes. EacheNodeB node may include a base transceiver system (BTS) thatcommunicates via an antenna system over an air-link with one or moreuser devices that are within range. The antenna system of an eNodeB nodemay include multiple antennas that are mounted on a radio tower toprovide a coverage area that is referred to as a “cell.” The BTS maysend radio frequency (RF) signals to user devices and receive radiosignals from user devices.

The core network 108 may provide telecommunication and datacommunication services to multiple user devices. For example, the corenetwork 108 may connect the user devices to other telecommunication anddata communication networks, such as the Internet and a public switchedtelephone network (PSTN). Accordingly, data packet communications viathe core network 108 and the Internet may support a variety of services.In various embodiments, the core network 108 may include variouscomponents, not illustrated in FIG. 1. For example, the core network 108may include an IP Multimedia Subsystem (IMS) core, an applicationfunction (AF), a Proxy Call Session Control Function (P-CSCF), an IMSregistrar server, an Interrogating CSCF (I-CSCF), a Serving CSCF(S-CSCF), a telephony application server (TAS), and the like.

With regards to the specifically illustrated components of FIG. 1, thecore network 108 may further include a provisioning engine 110, a policyengine 114, a charging engine 116, a gateway 118, and a data profilerepository 120. In some aspects, the data profile repository 120 storesvarious data profiles (i.e., data profiles 122) related to subscribers(i.e., users) of the wireless communication network 102. For example,the data profile repository 120 may function as a policy solutiondatabase to store subscriber profiles, quota, and state information. Insome aspects, data profile repository 120 may store subscriber profileinformation (e.g., service identifiers and corresponding subscriptionplans), as well as inter-session state information (e.g. usage and quotatracking). In some implementations, the data profile repository 120 mayinclude a user data repository (UDR) and/or a subscription datarepository (SDR).

The provisioning engine 110 is configured to prepare and/or equipvarious components of the core network 108 to allow existing and/or newservices to be provided to subscribers. In some examples, theprovisioning engine 110 may configured one or more network components toprovide subscribers with access to data and technology resources of thewireless communication network.

In some aspects, the provisioning engine 110 may monitor access rightsand privileges to ensure the security for the resources of the corenetwork 108 as well as user privacy. The provisioning engine 110 mayalso ensure compliance and minimize the vulnerability of the corenetwork 108 to penetration and abuse.

As will be described in more detail below, when a user device (e.g.,user device 104) attempts to establish a data session (e.g., datasession 134) with the wireless communication network 102, theprovisioning engine 110 may retrieve one or more data profiles 122 fromthe data profile repository 120 based on a service identifier 132associated with the user device 104. In some examples, the serviceidentifier 132 is a Mobile Station International Subscriber DirectoryNumber (MSISDN) associated with a subscriber of the wirelesscommunication network 102. However, in other examples, the serviceidentifier 132 may be an International Mobile Equipment Identity (IMEI),an International Mobile Subscriber Identity (IMSI), or some other uniqueidentifier associated with the user device 104.

The provisioning engine 110 may then forward the data profiles 122 toone or more components of the core network 108, such as the policyengine 114 and the charging engine 116. In some examples, the dataprofile 122 includes a service identifier (e.g., service identifier 132)and subscription information (e.g., plan details) associated with asubscriber.

The policy engine 114 may be a software component that determines policyand enforces policy rules and serves to establish calls and/or datasessions between the user device 104 and the wireless communicationnetwork 102. In various embodiments, the policy engine 114 may be aPolicy and Charging Rules Function (PCRF) or another equivalent corenetwork component of the wireless communication network 102.Accordingly, the Policy engine 114 may establish one or more policiesthat govern the establishment/performance of the data session 134. Insome examples, the policy engine 114 implements the policy for a datasession based on the data profile 122 as well as on one or more usagemetrics maintained by the charging engine 116.

The charging engine 116 may enable the wireless communication network102 to monitor the services, such as data, voice, text, etc., that areused by each subscriber, and charge the subscribers in real-time basedon service usage. In various embodiments, the charging engine 116 may bean Online Charging System (OCS) or another equivalent core networkcomponent of the wireless communication network 102. As shown in FIG. 1,the charging engine 116 may be configured to maintain a data store 112that includes various counters related to a subscriber's usage of thewireless communication network 102. For example, FIG. 1 illustrates thedata store 112 as including at least one service ID 136, a correspondingcounter, referenced by a counter ID 138, as well as a correspondingcounter status 140. In some examples, the counter status 140 representsthe current value of the counter (e.g., 1 GB of data used, 200 textmessages sent, etc.). However, the counter status 140 may also includeother information, such as the amount left (e.g., 2 GB of dataremaining, 600 text messages remaining, etc.). In yet another example,the counter status 140 may be a flag that identifies whether aparticular subscriber's “bucket” has been filled (e.g., a flagindicating there is data remaining for this subscriber on their plan, aflag indicating there are no text messages remaining for this subscriberon their plan, etc.). In some aspects, the charging engine 116 isconfigured to create and monitor the various counters based on the dataprofile 122 received from the provisioning engine 110.

The gateway 118 may include one or more servers and related componentsthat are tasked with providing connectivity between the wirelesscommunication network 102 and the user devices (e.g., the user device104) by acting as a point of entry and exit for data traffic.Accordingly, the gateway 118 may perform functions such as policyenforcement, packet filtering, packet screening, and/or chargingsupport. In various embodiments, the gateway 118 may be a Packet DataNetwork Gateway (PGW) or another equivalent core network component ofthe wireless communication network 102. In some aspects, the gateway 118may perform the policy enforcement for a data session (e.g., datasession 134) based on the one or more rules 130 received from the policyengine 114.

In various embodiments, the policy engine 114, the charging engine 116,and the gateway 118 may act in concert to aid in the establishment ofthe data session 134 between the user device 104 and the wirelesscommunication network 102. For example, as mentioned above, an attemptto establish a data session (e.g., data session 134) by a user device(e.g., user device 104) may trigger the provisioning engine 110 toretrieve one or more data profiles 122 from the data profile repository120 based on a service identifier 132 associated with the user device104. The provisioning engine 110 may then forward the data profiles 122to the policy engine 114 and the charging engine 116.

The provisioning of the data profile 122 may trigger the policy engine114 to initiate communication with the charging engine 116 by sending astatus request message 124 to the charging engine 116. In some examples,the status request message 124 includes the service identifier (e.g.,service identifier 132) and is a request for the status of one or morecounters associated with the service identifier.

Accordingly, the charging engine 116 may attempt to retrieve the statusof a counter associated with the service identifier by querying the datastore 112. However, as discussed above, the policy engine 114 and thecharging engine 116 are asynchronous systems. That is, the chargingengine 116 may not have received and/or processed the data profile 122by the time the status request message 124 is received at the chargingengine 116. Thus, in this situation, there would be no serviceidentifier included in the data store 112. In conventional systems, thecharging engine 116 would then generate and send an error message to thepolicy engine 114. In response to receiving the error message, thepolicy engine 114 would then prevent the establishment of the datasession 134. In some examples, in order for the user device 104 toreattempt to establish a data session the user device 104 may berequired to complete a power recycle (e.g., power off and power on).

Aspects of the present disclosure overcome these limitations byproviding a charging engine 116 that is configured to generate and senda response message 126 that includes nominal data. The nominal data mayenable the policy engine 114 to implement a default policy for allowingthe user device 104 to establish the data session 134. For example, theresponse message 126 may be formatted similar to a response message thatis provided when the charging device 116 has indeed been provisioned bythe provisioning engine 110 and where the charging engine 116 would beactively monitoring one or more counters in the data store 112associated with the corresponding service ID. However, since there is nocounter for that service ID yet in the data store 112, the chargingengine 116 may generate the response message 126 to include nominal(e.g., ‘dummy’) data. In some aspects, the nominal data is predeterminedand known by both the charging engine 116 and the policy engine 114. Thepolicy engine 114 may further be configured to recognize any responsemessage 126 that includes the nominal data and in response theretoimplement a default policy for the data session 134.

Implementation of a default policy by the policy engine 114 may includethe policy engine 114 determining a service level for a data sessionbetween the user device and the wireless communication network 102(e.g., default policy includes limiting the data session to 2G dataonly). In some examples, the default policy is the same for allsubscribers and is implemented by the policy engine 114 independent ofany subscription information (e.g., data profile 122) associated withthe user device 104 that is attempting to establish a data session.However, in other examples, the policy engine 114 may determine theservice level on a subscriber to subscriber basis. That is, the policyengine 114 may determine a service level based on the data profile 122received from the provisioning engine 110. For example, if the dataprofile 122 indicates that the subscriber associated with the serviceidentifier 132 is currently subscribed to a 4G data plan, the policyengine 114 may send one or more rules 130 to the gateway 118 to enablethe data session 134 utilizing 4G data. However, if the data profile 122indicates that the subscriber is currently subscribed to a 3G-only plan,then the policy engine may send rules 130 to the gateway 118 to limitthe data session 134 to 3G-only data.

In some examples, communication between the policy engine 114 and thecharging engine is over an Sy interface (e.g., interface 128). The Syinterface enables the transfer of information relating to subscriberspending from charging engine 116 to the policy engine 114 and maysupport one or more of the following functions: (1) the request ofpolicy counter status reporting from the policy engine 114 to thecharging engine 116 (e.g., by way of status request message 124); (2)the notification of counter status from the charging engine 116 to thepolicy engine 114 (e.g., by way of response message 126); and (3) thecancellation of counter status reporting from policy engine 114 to thecharging engine 116.

In some examples, the status request message 124 is a spending limitrequest (SLR) message communicated from the policy engine 114 to thecharging engine 116 over an Sy interface (e.g., interface 128).Similarly, the response message 126 may be spending-status notificationrequest (SNR) message communicated from the charging engine 116 to thepolicy engine 114 over an Sy interface.

In further aspects, after the charging engine 116 has sent the responsemessage 126, including the nominal data, to the policy engine 114, thecharging engine 116 may subsequently be provisioned with the appropriatedata profile 122 corresponding to the service identifier 132.Accordingly, the charging engine 116 may then update the data store 112to include a counter and the corresponding service identifier 132. Thecharging engine 116 may then generate and send an updated responsemessage (e.g., response message 126) to the policy engine 114. Theupdated response message may be formatted similar to the previousresponse message but, rather than including nominal data, may includeactual data related to the counter and counter status now included inthe data store 112.

In some examples, upon receiving the updated response message, thepolicy engine may then switch from the default policy to an updatedpolicy that is based on both the data profile 122 and the actual statusof the counter associated with the service identifier 132.

Example Computing Device Components

FIG. 2 is a block diagram showing various components of one or morecomputing devices that support the core network 108 of the wirelesscommunication network 102 for implementing default data sessions. Thecomputing devices 200 may include a communication interface 202, one ormore processors 204, memory 206, and hardware 208. The communicationinterface 202 may include wireless and/or wired communication componentsthat enable the computing devices 200 to transmit data to and receivedata from other networked devices. The hardware 208 may includeadditional user interface, data communication, or data storage hardware.For example, the user interfaces may include a data output device (e.g.,visual display, audio speakers), and one or more data input devices. Thedata input devices may include, but are not limited to, combinations ofone or more of keypads, keyboards, mouse devices, touch screens thataccept gestures, microphones, voice or speech recognition devices, andany other suitable devices.

The memory 206 may be implemented using computer-readable media, such ascomputer storage media. Computer-readable media includes, at least, twotypes of computer-readable media, namely computer storage media andcommunications media. Computer storage media includes volatile andnon-volatile, removable and non-removable media implemented in anymethod or technology for storage of information such ascomputer-readable instructions, data structures, program modules, orother data. Computer storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD), high-definition multimedia/data storage disks, orother optical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other non-transmissionmedium that can be used to store information for access by a computingdevice. In contrast, communication media may embody computer-readableinstructions, data structures, program modules, or other data in amodulated data signal, such as a carrier wave, or other transmissionmechanism. In various embodiments, the processors 204 and the memory 206of the computing devices 200 may execute the policy engine 114, thecharging engine 116, the gateway 118, as well as other components (e.g.,provisioning engine 110) of the core network 108.

Example Processes

FIG. 3 is a flow diagram of an example process 300 for establishing adefault data session in a wireless communication network. FIG. 4 is aflow diagram of an example process 400 for switching from a default datasession to an updated data session for a user device and a wirelesscommunication network. Processes 300 and 400 are illustrated as acollection of blocks in a logical flow chart, which represents asequence of operations that can be implemented in hardware, software, ora combination thereof. In the context of software, the blocks representcomputer-executable instructions that, when executed by one or moreprocessors, perform the recited operations. Generally,computer-executable instructions may include routines, programs,objects, components, data structures, and the like that performparticular functions or implement particular abstract data types. Theorder in which the operations are described is not intended to beconstrued as a limitation, and any number of the described blocks can becombined in any order and/or in mirror to implement the process. Fordiscussion purposes, the processes 300 and 400 are described withreference to the architecture 100 of FIG. 1.

Process block 302, of FIG. 3, illustrates the charging engine 116maintaining the data store 112 to include at least one counter (e.g.,counter ID 138) and a corresponding at least one service identifier(e.g., service ID 136). In one aspect, maintaining the data store 112may include creating, initializing, and/or updating a counter based ondata profiles (e.g., data profile 122) received from the provisioningengine 110. As mentioned above, the data profile 122 may include theservice identifier 132 and the current plan information for a subscriberassociated with the service identifier 132. The data profile 122 mayalso include a current status and/or state of the subscriber's usagewith respect to their data plan. For example, the data profile 122 mayindicate that a subscriber is currently subscribed to a data plan thatlimits monthly data usage to 2 GB and that they have used 1 GB of dataso far this month. Accordingly, the charging engine may create a counterin the data store 112 to monitor the subscriber's data usage and alsomay initialize the counter to 1 GB.

Next, in process block 304, the policy engine 114 obtains a first dataprofile (e.g., data profile 122) and a corresponding first serviceidentifier. In some aspects, the policy engine 114 receives the firstdata profile from the provisioning engine 110 in response to a userdevice (e.g., user device 104) attempting to establish a data sessionwith the wireless communication network 102.

Next, in process block 306, the policy engine 114 generates a statusrequest message 124 that includes the service identifier included in thedata profile 122. Also, in process block 306, the policy engine 114sends the status request message 124 to the charging engine 116 viainterface 128 to request for a status of a counter associated with theservice identifier.

In decision block 308, the charging engine 116 determines whether thefirst service identifier is included in the data store 112. If so,process block 310 includes the charging engine 116 generating andsending a response message (e.g., response message 126) to the policyengine 114. In process block 310, the generation of the response messageincludes incorporating the service identifier as well as a status of thecounter associated with the service identifier (e.g., service ID 136 andcounter status 140). The response message is then sent by the chargingengine 116 to the policy engine 114.

If, however, in decision block 308, the charging engine 116 determinesthat the first service identifier is not included in the data store 112(i.e., the charging engine 116 has not yet been provisioned with thedata profile 122), the process 300 proceeds to process block 312. Inprocess block 312, the charging engine 116 generates a default responsemessage. The default response message is then sent by the chargingengine 116 to the policy engine 114. As mentioned above, the defaultresponse message includes a similar format (e.g., SNR message) as theresponse message that would be sent in process block 310. However, thedefault response message includes nominal data rather than data thatrepresents an actual active counter in the data store 112.

The nominal data may be predetermined and known to both the policyengine 114 and the charging engine 116. Accordingly, in decision block314, the policy engine 114 receives the response message and determineswhether the response message is a default response message bydetermining whether the response message includes the nominal data. Ifso, process 300 proceeds to process block 316, where the policy engine114 is triggered to implement a default policy. As mentioned above,implementing the default policy may include the policy engine 114sending one or more rules 130 to the gateway 118 to allow theestablishment of the data session 134 in accordance with a service levelpolicy corresponding to the default policy (e.g., 3G only data).

If, however, in decision block 314, the policy engine 114 determinesthat the response message does not include the nominal data, thenprocess 300 proceeds to process block 318, where the policy engine 114implements a policy based on the counter status included in the responsemessage 126. In some examples, implementing the policy in this scenarioincludes determining a service level for the data session 134 based onboth the data profile 122 and on the status of the counter (e.g., thesubscriber has purchased a 3G data plan, and has not exceeded their datausage limit, so allow 3G data for data session 134).

Turning now to FIG. 4, process 400 illustrates an example process forswitching from a default policy for the data session 134 to an updatedpolicy for the data session 134. That is, the above described process300 is a process for creating a default policy prior to the chargingengine 116 being provisioned with the data profile, while process 400includes a process for updating the policy after the charging engine 116is subsequently provisioned with the data profile 122.

For example, in process block 402, the charging engine 116 receives afirst data profile (e.g., data profile 122) associated with a firstservice identifier (e.g., service identifier 132). As mentioned above,the charging engine 116 may receive the first data profile from theprovisioning engine 110, where the delay in receiving the first dataprofile is due to the asynchronous nature of the charging engine 116with respect to the policy engine 114.

Regardless, once the charging engine 116 receives the first dataprofile, process block 404 includes updating the data store 112 toinclude a first counter and the corresponding first service identifier.In some aspects, updating the data store 112 includes creating one ormore counters based on the data profile 122. For example, the dataprofile 122 may indicate that the subscriber has purchased a data planthat includes a data usage limit as well as an SMS messaging limit.Accordingly, the charging engine 116 may create a counter to monitordata usage of the subscriber as well as a counter to monitor SMSmessages exchanged by the subscriber.

Next, in process block 406, the charging engine 116 generates and sendsan updated response message to the policy engine 114. However, ratherthan generating the response message to include nominal data, as wasdone in process block 312, in this case the response message isgenerated to include the actual data, including the first serviceidentifier and a status of the counter associated with the first serviceidentifier.

Process block 408 illustrates the policy engine 114 receiving theupdated response message. Based on receiving the response message, thepolicy engine 114 may switch from the previously implemented defaultpolicy to an updated policy. In some aspects, the updated policyreflects the actual service level to be accorded to the subscriber basedon the data profile 122 and on the status of the counter.

FIG. 5 is a diagram of an example response message 502 generated by acharging engine of a wireless communication network. Response message502 illustrates an example format of the response message 126,regardless of whether the response message 126 included nominal data totrigger a default policy for the data session or whether the responsemessage 126 is to include data representing an actual counter statusincluded in the data store 112. In the illustrated example, responsemessage 502 is an SNR message communicated from the charging engine 116to the policy engine 114 over an Sy interface. As shown in FIG. 5,response message 502 includes fields 504, 506, 508, and 510. In someexamples one or more of the fields 504, 506, 508, and 510 may bemodified to include the nominal data when generating response message502 as a default response message.

Field 504 is illustrated as a ‘FeatureName’ field. When generating theresponse message 502 to include the actual data (i.e., not the nominaldata), the field 504 may identify a type or particular data planpurchased by the subscriber. In some systems, the policy engine 114 maybe required to query the data profile repository 120 to obtain the dataprofile 122 each time a response message 126 is received at the policyengine 114. That is, each time the policy engine 114 receives an updateto a counter maintained by the charging engine 116, the policy engine114 may be required to send a request to, and wait for a response from,the data profile repository 120. This process of obtaining the dataprofile 122 may add unwanted delay in the implementation of one or morepolicies by the policy engine 114. Accordingly, the charging engine 116may maintain information regarding the subscriber's plan correspondingto a counter included in the data store 112. The field 504 may bepopulated to signal to the policy engine 114, the data plan associatedwith this subscriber. Thus, this may enable the policy engine 114 toimplement a policy for the data session without having to request thedata profile 122 from the data profile repository 120.

The field 506 is illustrated as a policy counter identifier field andmay correspond to the counter ID 138 illustrated in FIG. 1. The field508 is illustrated as a policy counter status field and may correspondto the counter status 140 of FIG. 1. The field 510 is illustrated as apending policy counter information field.

FIG. 6 is a block diagram showing an example call flow for establishinga default data session and for switching between the default datasession and an updated data session for communications between a userdevice and a wireless communication network. The example call flow 600illustrates the communications that are sent between the variouscomponents of the wireless communication network 102, in which thecomponents may include a UD 602, PGW 604, a PCRF 606, and an OCS 607. Inone example, UD 602 corresponds to user device 104 of FIG. 1, PGW 604corresponds to gateway 118 of FIG. 1, PCRF 606 corresponds to policyengine 114 of FIG. 1, and OCS 608 corresponds to charging engine 116 ofFIG. 1. Also illustrated in FIG. 6 is a data store 622 and a dataprofile 624. Data store 622 may correspond, in some examples, to datastore 112 of FIG. 1. Similarly, data profile 624 may correspond, in someexamples, to data profile 122 of FIG. 1.

FIG. 6 illustrates the UD 602 attempting to establish a data sessionwith the wireless communication network by exchanging one or moreinitialization messages 610 with the PGW 604. In response, the PGW 604may send a credit control request (CCR) command 612 to the PCRF 606.Once provisioned with a data profile from the provisioning engine (e.g.,provisioning engine 110 of FIG. 1), the PCRF 606 may send an SLR 614message to the OCS 608. In some examples, the SLR 614 messagecorresponds to the status request message 124 of FIG. 1. Next, inresponse to determining that the OCS 608 has not yet been provisioned,the OCS 608 generates and sends the SNR 616 message to include thenominal data. The SNR 616 message may correspond, in some examples, toresponse message 126 of FIG. 1. Upon receiving the SNR 616 message, thePCRF 606 may examine the SNR 616 message and determine that it includesthe nominal data. If so, the PCRF then sends a credit control answer(CCA) command 618 to the PGW 604. The CCA command 618 may correspond, insome examples, to the one or more rules 130 of FIG. 1. In response toreceiving the CCA 618 command, the PGW 604 may enforce the defaultpolicy to enable the data session 620.

FIG. 6 also illustrates the subsequent provisioning of the OCS 608. Forexample, as shown, the data store 622 is provisioned with the dataprofile 624 after the OCS 608 has already sent the SNR 616 (i.e.,default response message) to the PCRF 606. Thus, the OCS 608 maygenerate another SNR message, shown in FIG. 6 as SNR 626 message. Inresponse to receiving the SNR 626 message, the PCRF 606 may switch fromimplementing the default policy to an updated policy that moreaccurately enforces policies associated with a subscriber's actual dataplan. To that end, PCRF 606 may send another CCA command, shown in FIG.6 as CCA 628 command, to the PGW 604. In response to receiving the CCA628 command, the PGW may enforce one or more rules for the data session630 in accordance with the updated policy.

CONCLUSION

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as exemplary forms ofimplementing the claims.

What is claimed is:
 1. A computer-implemented method, comprising:maintaining, at a charging engine of a wireless communication network, adata store that includes at least one counter and a corresponding atleast one service identifier of one or more subscribers of the wirelesscommunication network, wherein maintaining the data store includesupdating the at least one counter based on a data profile associatedwith the at least one service identifier; receiving a status requestmessage, at the charging engine from a policy engine of the wirelesscommunication network, wherein the status request message is a requestfor information on a counter associated with a service identifier;determining whether the service identifier is included in the data storein response to receiving the status request message; generating adefault response message in response to determining that the serviceidentifier is not included in the data store, wherein the defaultresponse message includes nominal data; and sending the default responsemessage to the policy engine to enable the policy engine to implement adefault policy for allowing a data session between a user deviceassociated with the service identifier and the wireless communicationnetwork, wherein the default policy is determined for a service levelassociated with the one or more subscribers of the wirelesscommunication network.
 2. The computer-implemented method of claim 1,further comprising: receiving, at the charging engine, a data profileassociated with the service identifier; updating the data store toinclude the counter and the service identifier based on the dataprofile; generating an updated response message to include the serviceidentifier and a status of the counter; and sending the updated responsemessage to the policy engine to trigger the policy engine to switch fromthe default policy to an updated policy for the data session.
 3. Thecomputer-implemented method of claim 1, wherein the service identifiercomprises a Mobile Station International Subscriber Directory Number(MSISDN) associated with a subscriber of the wireless communicationnetwork.
 4. The computer-implemented method of claim 1, whereinreceiving the status request message comprises receiving a spendinglimit request (SLR) message over an Sy interface between the policyengine and the charging engine.
 5. The computer-implemented method ofclaim 1, wherein sending the default response message comprises sendinga spending status notification request (SNR) message over an Syinterface between the policy engine and the charging engine.
 6. Thecomputer-implemented method of claim 5, wherein the SNR messagecomprises one or more fields that include the nominal data.
 7. Thecomputer-implemented method of claim 6, wherein the one or more fieldsinclude at least one of: (1) a policy counter identifier field, (2) apolicy counter status field, or (3) a pending policy counter informationfield.
 8. A computer-implemented method, comprising: generating, by apolicy engine of a wireless communication network, a status requestmessage to include a service identifier of a subscriber of the wirelesscommunication network, wherein the status request message is a requestfor a status of a counter associated with the service identifier;sending the status request message to a charging engine of the wirelesscommunication network; receiving a response message from the chargingengine in response to sending the status request message; determiningwhether the response message includes nominal data; determining adefault policy for a service level associated with the subscriber of thewireless communication network; and implementing the default policy forallowing a default data session between a user device associated withthe service identifier and the wireless communication network inresponse to determining that the response message includes the nominaldata.
 9. The computer-implemented method of claim 8, further comprising:receiving, at the policy engine, an updated response message from thecharging engine, wherein the updated response message includes theservice identifier and the status of the counter; and switching from thedefault policy to an updated policy for the data session.
 10. Thecomputer-implemented method of claim 8, wherein the service identifiercomprises a Mobile Station International Subscriber Directory Number(MSISDN) associated with the subscriber of the wireless communicationnetwork.
 11. The computer-implemented method of claim 8, wherein sendingthe status request message comprises sending a spending limit request(SLR) message over an Sy interface between the policy engine and thecharging engine.
 12. The computer-implemented method of claim 8, whereinreceiving the response message comprises receiving a spending statusnotification request (SNR) message over an Sy interface between thepolicy engine and the charging engine.
 13. The computer-implementedmethod of claim 12, wherein the SNR message comprises one or more fieldsthat include the nominal data.
 14. The computer-implemented method ofclaim 13, wherein the one or more fields include at least one of: (1) apolicy counter identifier field, (2) a policy counter status field, or(3) a pending policy counter information field.
 15. Thecomputer-implemented method of claim 8, wherein implementing the defaultpolicy comprises sending one or more rules to a gateway of the wirelesscommunication network for allowing the default data session.
 16. One ormore computing devices of a wireless communication network, the one ormore computing devices comprising: one or more processors; and memoryhaving instructions stored therein, the instructions, when executed bythe one or more processors, cause the one or more processors to performacts comprising: maintaining, at a charging engine of the wirelesscommunication network, a data store that includes at least one counterand a corresponding at least one service identifier of one or moresubscribers of the wireless communication network, wherein maintainingthe data store includes updating the at least one counter based on atleast one data profile associated with the at least one serviceidentifier; obtaining, at a policy engine of the wireless communicationnetwork, a data profile and a corresponding service identifier of asubscriber of the wireless communication network, wherein the policyengine is configured to implement a policy for establishing a datasession between the wireless communication network and a user deviceassociated with the service identifier based on: (1) the data profileand (2) a status of a counter associated with the service identifier;generating, by the policy engine, a status request message to includethe service identifier, wherein the status request message is a requestfor the status of the counter; sending the status request message to thecharging engine; receiving the status request message at the chargingengine; determining whether the service identifier is included in thedata store in response to receiving the status request message;generating, by the charging engine, a default response message inresponse to determining that the service identifier is not included inthe data store, wherein the default response message includes nominaldata; sending the default response message to the policy engine;receiving the default response message from the charging engine;determining, by the policy engine, whether the default response messageincludes the nominal data; and implementing, by the policy engine, adefault policy for allowing a default data session between the userdevice and the wireless communication network in response to determiningthat the default response message includes the nominal data, wherein thedefault policy is determined for a service level associated with the oneor more subscribers of the wireless communication network.
 17. The oneor more computing devices of claim 16, wherein the acts furthercomprise: receiving, at the charging engine, the data profile associatedwith the service identifier; updating the data store to include thecounter and the service identifier based on the data profile;generating, by the charging engine, an updated response message toinclude the service identifier and the status of the counter; sendingthe updated response message to the policy engine; receiving, at thepolicy engine, the updated response message; and switching, by thepolicy engine, from the default policy to an updated policy for the datasession.
 18. The one or more computing devices of claim 16, wherein theservice identifier comprises a Mobile Station International SubscriberDirectory Number (MSISDN) associated with the subscriber of the wirelesscommunication network.
 19. The one or more computing devices of claim16, wherein the default response message comprises a spending statusnotification request (SNR) message comprising one or more fields thatinclude the nominal data, wherein the one or more fields include atleast one of: (1) a policy counter identifier field, (2) a policycounter status field, or (3) a pending policy counter information field.